The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. The IMS is defined in the 3GPP Specification 23.228.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality and to provide services to end users.
The S-CSCF is the central node of the signaling plane. It is a SIP server, but performs session control as well. It uses Diameter Cx and Dx interfaces to download and upload user profiles to/from the user's Home Subscriber Server HSS). The S-CSCF handles SIP registrations, and is in the path of all signaling messages, so that it can inspect every message in a session. It decides to which application server(s) the SIP message will be forwarded for the provision of services and it provides routing services.
According to the principles outlined in the 3GPP technical specifications, [TS 32.260] and [TS 32.299] the S-CSCF also acts as a Charging Triggering Function (CTF) with regard to charging of users of the IMS infrastructure and services. Note, however, that although the discussion herein is based around the S-CSCF acting as the CTF, the principles described would be equally applicable to any IMS network node acting as the CTF.
Acting as the CTF in an IMS network requires the S-CSCF to perform a number of tasks in order to identify the correct charging signalling to apply that corresponds to, and is triggered by the user's session activity. The S-CSCF, when performing its normal routing actions for the SIP signalling events that it is handling, determines whether the SIP information represents a chargeable activity, and then which type of charging mechanism to apply. The charging mechanisms for IMS sessions are either Offline (post-paid) charging, using accounting messages, or online (pre-paid) charging, using credit control messages and procedures.
Information about IMS transactions is sent from the S-CSCF (or other IMS nodes) to a charging node that collects this information and stores it in the form of Charging Data Records (CDRs), which can then be used in whatever way the operator sees fit. The information collected in this way is categorized as charging information, but in fact it can be information relating to things other than charging (billing), such as a form of Deep Packet Inspection (DPI), statistics, security, traffic monitoring, etc.
FIGS. 2a and 2b illustrate the IMS architecture for offline and online charging respectively. As shown in FIG. 2a, for off-line charging the various IMS network entities that handle transactions, and might act as a CTF to generate charging information, communicate with a Charging Data Function (CDF) 20 over an Rf interface. The entities shown include: Breakout Gateway Control Function (BGCF) 22a, Media Gateway Control Function (MGCF) 22b, Media resource Function Controller (MRFC) 22c, SIP Application Server (AS) 22d, Proxy-CSCF (P-CSCF) 22e, Interrogating-CSCF (I-CSCF) 22f, and Serving-CSCF (S-CSCF) 22g. The CDF 20 communicates with a Charging Gateway Function (CGF) 24 over the Ga interface, which in turn communicates with the IMS billing domain 26 over the Bi interface.
As shown in FIG. 2b, for on-line charging, the IMS network entities 22a-22e communicate with an Online Charging System (OCS) 28, over the Ro interface. In the figure, for clarity, only the communications over the Ro interface between the MRFC 22c, SIP-AS 22d and S-CSCF 22g are shown although any network entity that handles or generates charging information that should be passed to the OCS 28 may act as a CTF and pass data over the Ro interface, including any of the other entities 22a-22g shown. The OCS 28 communicates directly with the IMS billing domain 26. In the case of the S-CSCF 22g, the charge-triggering information is sent via an IMS Gateway Function (IMS-GWF) 29 over the ISC interface and then over the Ro interface to the OCS 28.
As explained above, although the discussion below focuses on the S-CSCF, the same principles may be applied to any IMS node that acts as a CTF, including any of those listed above and shown in FIGS. 2a and 2b. 
FIG. 3 illustrates the signalling involved when a user entity, UE 30, initially registers with the IMS, in accordance with the procedure set out in 3GPP TS 24.229. On receiving an initial registration request 301 from a UE 30, a serving CSCF 32 sends a User Authorisation Request, UAR 302, to the users Home Subscriber Server, HSS 34, which returns a User Authorisation Answer, UAA 303. The CSCF 32 then sends a Media Authorisation Request, MAR 304 to the HSS 34, which returns a Media Authorisation Answer, MAA 305. The CSCF 23 then returns a 401 Unauthorised message 306 to the UE 30, which prompts the UE 30 to send a second Register request 307, and the procedure of exchanging UAR and UAA is repeated at 308 and 309. The CSCF 32 then sends a Server Assign Request 310 to the HSS 34, which returns a Server Assign Answer, SAA 311. The user profile information is passed to the serving CSCF 32 in the SAA message 311. Finally, the CSCF 32 sends a 200 OK message 312 to the UE 30 to indicate successful registration.
FIGS. 4a and 4b illustrate the signalling involved between, on one side a UE or an Application Server 40, and on the other side the IMS charging control system 44, via the S-CSCF 42, for, respectively, off-line and on-line charging. During IMS calls, charging-related information is passed from the S-CSCF42 to the charging control system (e.g. CDF or OCS as shown in FIGS. 2a and 2b) in order to construct CDRs. To pass the charging related information, offline charging uses the DIAMETER Accounting Request, ACR and Answer ACA messages, and online charging uses the DIAMETER Credit Control Request, CCR, and Answer, CCA, messages. The charging related information is passed in Attribute-Value Pairs (AVPs) within the ACR and CCR messages.
For off-line charging, as shown in FIG. 4a, a session is set up through the exchange of SIP INVITE and SIP 200 OK messages with a receiving peer (not shown) as indicated at 401-404. Once the session has been established, the S-CSCF 42 sends an Accounting Request, ACR, message 405 to the charging control system 44 (e.g. the CDF as shown in FIG. 2a), together with the charging-related information relating to the start of the session and the user identity and service information. The charging control 44 returns an Accounting Answer 406. When the session ends, as indicated by the sending of SIP BYE messages 407, 408, the S-CSCF 42 sends a further ACR 409 to the charging control system 44, together with the required information relating to the ending of the session, user identity and service information. The charging control system 44 returns an ACA message 410. The charging control system 44 creates CDRs using the information in the ACR messages 405, 409.
For on-line charging, as shown in FIG. 4b, when the UE/AS 42 sends the initial SIP INVITE message 411, the S-CSCF 42 immediately sends a Credit Control Request, CCR 412 to the charging control system (e.g. the OCS as shown in FIG. 2b). The CCR includes an indication that it is an initial credit control request and also provides a user identity and service information. Now the charging control performs a credit determination 412a of a number of service units that the user will initially be granted for the session, assuming the user has sufficient pre-paid credit. This information is provided back to the S-CSCF 42 in a Credit Control Answer, CCA 413. Now the S-CSCF can forward on the SIP Invite 414 to the receiving peer, and the session can be established as before with the return of SIP 200Ok messages 415, 416. While the session is in progress, the S-CSCF may send a CCR Update 417, for example to request grant of more service units if the initially granted service units are about to run out. The charging control system then performs another credit determination 417a and provided the user has sufficient credit, the charging control 44 grants additional service units by way of a CCA 418. At termination of the session, when the S-CSCF 42 receives a SIP BYE message 419, it sends a CCR 420 to the charging control 44 indicating termination and including the user identity, service units consumed and service information. The charging control system 44 then uses this information to calculate 420a an amount to debit the user, and returns a CCA message 421.
The above-described mechanisms deal with the mechanics of handling the data required for charging users, but provide no means of controlling charging for the system providers/operators. For example, different ACRs/CCRs may have different values to an operator based on the revenue that these provide. One user could generate a lot more revenue compared to another user, which makes the first user's ACR/CCRs more valuable to the operator. It is also common practice for internal calls within one operator's network to be charged at a flat rate or for free, which makes those ACR/CCRs less valuable.
The problem becomes more acute in the event of a system overload or a link failure between the CTF and the charging system. In such cases the CTF starts to write the ACR/CCRs to a local storage, such as a disk. If the situation persists the disk can quickly become full and in that case either new ACR/CCRs will be discarded, or will overwrite previously stored ACR/CCRs. This means that a less valuable ACR/CCR may be stored while a more valuable ACR/CCR is discarded or over-written, with the result that the operator will lose revenue. An overload situation could also arise in the charging system itself giving rise to a similar problem.
There are also situations where it would be desirable for the CTF to connect to different Charging systems for ACR/CCRs that have a higher value. For example, the operator might want to handle the more valuable ACR/CCRs in a specific charging system having higher security and more redundancy.
The present invention has been conceived with the foregoing problems in mind.